---
title: Drone-CI
sidebar_position: 2
---

**CI (持续集成-Continuous Integration) CD (持续部署-Continuous Deployment)**

可以通过自动化执行的方式, 减少从开发到部署这个过程中的人工参与

一来可以降低 **开发人员/运维人员** 的工作量, 二来也可以减少人工参与时可能出现的错误操作

理论上来说, 代码的 格式检查,编译错误,单元测试,打包,发布 等操作都可以放到这个过程中做

但是各个开发团队不同的需求, 使用的语言工具的不同, 最终落地实施的时候可能会千奇百怪, 没有个统一的做法

我在这儿就介绍一下我的环境

我使用的方案是 [gitea](https://gitea.io/zh-cn/) + [drone ci](https://www.drone.io/) 组合的cicd系统

Gitea 是一个轻量级的 DevOps 平台软件, 从开发计划到产品成型的整个软件生命周期, 他都能够高效而轻松的帮助团队和开发者

包括 Git 托管、代码审查、团队协作、软件包注册和 CI/CD, 它与 GitHub、Bitbucket 和 GitLab 等比较类似

Gitea 最初是从 Gogs 分支而来, 几乎所有代码都已更改

而 Drone-CI 是一个开源的 CI/CD 平台, 他可以与 Gitea 集成, 实现代码提交后自动构建、测试和部署

Drone-CI 支持多种编程语言和工具, 可以通过配置文件定义构建流程, 并且与 Docker 集成地可以说是 **天衣无缝** 

我放弃更加大众化的方案选择这个两个服务, 也是有现实原因的, 虽然从功能上来说 gitlab 更强, 但是对硬件资源的要求也更高

现阶段我的服务大部分都部署在 **树莓派** 上, 内存有限, 并且性能相对也不高, 所以就没有考虑高资源消耗的方案

![docker-stats](/img/gitea/gitea-drone-stats.webp)

上图是部署之后的资源占用情况, 内存使用比我见过的 gitlab + Jenkins 组合低至少 **两个数量级**, 非常适合资源受限的场景了

再加上我使用 k3s 管理服务, 代码仓库只要能做到 ci 即可, 代码提交后自动打包镜像推送到 nexus3 上, 然后根据心情手动重启更新pod

所以资源能省一点是一点, 取舍之后还是这个方案比较适合我的场景, 后续如果 gitea 的 action 落地了, 可能会考虑更换
